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Foreword 

This Technical Specification has been produced by the J - Generator. Partnership Project (3GPP). 

The contents of the present document are subject to continuing work within the TSG and may change following formal 
TSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TSG with an 
identifying change of release date and an increase in version number as follows: 

Version x.y.z 

where: 

x Ihe first digit 

1 presented to TSG for information; 

2 presented to TSO for approval; 

3 or greater indicates TSG approved document under change cootrol. 

y the second digit is incremented for all changes of substance, i.e. technical eaiancements, corrections, 
updates, etc. 

i Ihe third digit is incremented when editorial only changes have been iitcorporated in the document 



iOPP 



1 Scope 

The present document describes the stage 2 description (architectural solution and rationalities) for MBMS, which 
includes the elements necessary to realise the stage I requirements in 3GPP TS 22.146 [2]. 

Tne present document includes information applicable to network operators, service providers and manufacturers, 

2 References 

Tne following documents contain provisions which, through reference in this text, constitute provisions of the present 
document 

• References are cither specific (identified by date of publication, ediUon number, version number, etc.) or 
non-specific. 

• For a specific reference, subsequent revisions do not apply, 

• For a non-specific reference, the latest version applies. In the case of a reference to a 3GPP document (including 
a GSM document), a non-specific reference implicitly refers to the latest version of that document in the saint 
ReltastasthtpmenidocumtM. 

[1] 3GPPTR2I.905: "Vocabulary for 3GPP Specifications". 

[2] 3GPP TS 22,146: "Multimedia Broadcast/Multicast Service; Stage I". 

[3] 3GPP TS 23.107; "Quality of Service (QoS) concept and architecture". 

[4] 3GPPTS 29.061: "Intenrorfciiig between the Public Land MobaeNetwork{PLMN) supporting 

packet based services and Packet Data Networks (PDN)\ ' 

[J] 3GPP TS 33 .246: "Security of Multimedia Broadcast/Multicast Service" 

3 Definitions and abbreviations 

3.1 Definitions 

For the purposes of the present document, the terms and definitions defined in 3GPP TS 21.905 (11 and 3GPP TS 
22. 1 46 [2] and the following epply. 

MBMS Service Announcement: Mechanism to allow users to be informed about the MBMS user services available. 

MBMS Bearer Service: the service provided by the PS Domain to MBMS User Services to deliver IP multicast 
datagrams to multiple receivers using minimum network and radio resources. 

MBMS User Service: the MBMS service provided to the end user by means of the MBMS Bearer Service and possibly 
othercapabiliq'es, 

MBMS Service Area: The area in which a specific MBMS Bearer Service is available, it is defined individually per 
MBMS Bearer Service, 

3.2 Abbreviations 

For the purposes of the present document, the abbreviations in 3GPP TS 21.905 (I) and 3GPPTS 22.141 (2] apply. 



3GPP 



36PPT8 21246 V.6.1.0 (2003-12) 



)GPP TS 23.248 V.8.1.0 (2003-12) 



4 MBMS Architecture 
4.1 Overview 

Tk MBMS bearer soviet offen two modes: 
' Broadcast Mode 
• Multicast Mode 

architecture and by addmoo of a number of new fuaetionat entities. w " wo ™ 1 ™ 

• managing the MBMS bearer nervioe activation status of UEs (in (be case of multicast mode) 

• muaourcing authorisation decisions to the MBMS User Service (lo. to the BM-SC) (in the case of multicast 
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Figure 1: Reference architecture to support MBMS 

4.3 MBMS Specific Reference points 
4.3.1 Gmb 

MBMS bearer service specific Gmb signalling: 

• The GGSN establishes the MBMS bearer context and regiaten at BM-SC. 

• The GGSN or the BM-SC releases the MBMS bearer contexl and de-register the GGSN from the BM-SC. 

• The BM-SC indicates session start and stop to the GGSN including session attributes like QoS or MBMS service 
User specific Gmb signalling: 

• The BM-SC authorises the user specific MBMS mulUcast service activation Ooin) at the GGSN. 

• I!j ^SN reports to the BM-SC the successful user specific MBMS multicast activstiot Uoin) to allow the 
BMSC to synchron.se the BM-SC UE MBMS context and charging with the MBMS UE contexts in SGSN and 
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The BM-SC initiates the deactivation oft user specific MBMS bearer service when the MBMS user service is 



This is illustrated with the following example of timeline: 
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4.4 MBMS Service Provision 
4.4.1 MULTICAST MODE 

Reception of an MBMS MULTICAST service is enabled by certain procedures thai are illustrated in the Figure below. 




Figure 2: Phases of MBMS Multicast service provision 

Tie phases subscription, joining and leaving are performed individually per user. The other phases are performed for a 
service, i,e. for all users interested in the related service. He sequence of phases ouy repeat, e.g. dependiog era the need 
to transfer data. Al»subscription,joining, leaving, service announcement as well as MBMS notiEcation mayrun in 
parallel to other phases. 
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Figure 3: Timeline example 

4.4.1.1 Subscription 

Establishea the relationship between the user and the service provider, which allows the user to receive the related 
MBMS multicast service. 

Service Subscription is the agreement of a user to receive servieefs) offered by the openstot. Subscription information u 
recorded in the appropriate databases) in the operator's network. 

4.4.1.2 Service announcement 

MBMS user service announcement/discovery mechanisms shall allow users to request or be informed about the range 
of NfflMS user services avmlable. This includes operator specific MBMS user services as weU a> services r>om content 
providers outs.de of the PLMN. Service announcement « used to distribute to usn, infomution .bout the service, 
parameters required for service activation (e.g. IP multicast address) and possibly other service related parameters (e.g. 
service start time), 

Operators/service providers may consider several service discovery mechanisms. This could include standard 

WKtannras such u SMS^ or o^ending on the apabiltty of the tenninal, t^ltcatioiti tbat ea«>urage user inienogaboa 

it* method chosen to inform users about MBMS user services may have to account for the user 1 s location, (e.g. current 

10 * e ^!^ 0r VPLMN) - U|OT wh0 hlve 001 ^ to > MBMS user service should also be able to 
discover MBMS user services. 



Tie following could be considered useful for MBMS i 



lot exhaustive);- 



MBMS Broadcast mode to advertise MBMS Multicast and Broadcast user Services 
MBMS Multicast mode to advertise MBMS Multicast user Services 
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PUSH mechanism (WAP. SMS-PP, MMS) 
URL (HTTP, FTP) 



4.4.1.3 Joining 

Joining MBMS multjctti activation by the user) is the process by which a subscriber joins (becomes a member on 

4.4.1.4 Session Start 

^taitepofeii which theBM-SCisrcady to send data. This can be identified with the start of a -Multicast 
sess.cn as defined in (he Stage 1 . Session Start occurs indepeodrntly of activation of the service by the user - i c a 

4.4.1.5 MBMS notification 

Informs the UEs about forthcoming (and potentially about ongoing) MBMS multicast data transfer. 

4.4.1.6 Data transfer 

It it the phase when MBMS data an transferred to the UEs. 
4.4.1.7 



4.4.1,8 



Leaving 



4.4.2 Multicast Mode timeline 



Period between Service Announcement and Session Start 



4.4.2.1 
ItsTS 

4.4.2.2 Period between Service Announcement and Service Subscription 

Service Subscription can be done anytime before or after Service announcement 

4.4.2.3 Period between Service Announcement and Joining 



time of their choosing so that the period between announcement and j 



I joining may be very long or very short 
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4.4.2.4 Period between Joining and Session Start 

Some MBMS bearer services may be 'always on'. In this case, Joining can take place starting immediately after Service 
Announcement and possibly many hours before, or after, Session Start. 

In other cases, if a Session Start time is known, Joining may take place immediately before Session Start or after 
Session Start. For these services, the announcement may contain some indication of e time period within which users 
should choose a time to Join the MBMS bearer service. 

4.4.2.5 Period between Session Start and First Data Arrival 

Session Start indicates that the transmission is about to start The time delay between a Session Start indication and 
actual data should be long enough for the network actions required at Session Start to take place e.g. provision of 
service information to the UTRAN, establishment of the bearer plane. 

Session Start may be triggered by an explicit notification from the BM-SC. In the case of bearer plane resources which 
are set-up after the start of session data transmission, the network is not required to buffer the session data and loss of 
data can be assumed. 

4.4.2.6 Period between Session Start and Session Stop 

When the BM-SC knows that there is no more data to be sent for a long idle period", it should indicate Session Stop to 
the network, causing the release of bearer resources, However, if this idle period with no data is short, this may not be 
appropriate as it brings more signalling and processing. 

There is no absolute value on the duration of this long idle period", The order of magnitude (i.e. is it closer to 30 
seconds or 30 minutes) is to be defined taking into account UTRAN coMtrainls. 



4.4.3 BROADCAST MODE 

An example for the phases of MBMS broadcast service provision is described in the figure below; 
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Figure 4: Phases of MBMS broadcast service provision 

The sequence of phases may repeat, e.g. depending on the need to transfer data. It is also possible that the service 
announcement and MBMS notification phase may ran in parallel with other phases, in order lo inform UEs which have 
Ml yet received the related service, 




Figure 5: Broadcast service timeline 

4.4.3.1 Service announcement 

Informs UEs about forthcoming MBMS user services. Also see section on Multicast node (4.4.1,2) 

4.4.3.2 Session Start 

Session Start is the point at which the BM-SC is ready to send data, This can be identified with the start of a "Broadcast 
session" as defined to the Stage 1, Session Start occurs independently of Service Activation by the user- i.e. a given 
user may activate the service before or after the start of the session. Session Start is the trigger for bearer resource 
establishment for MBMS data transfer. 

4.4.3.3 MBMS notification 

Informs the UEs about forthcoming (and potentially about ongoing) MBMS broadcast data transfer. 

4.4.3.4 Data transfer 

It is the phase when MBMS data are transferred to the UEs. 

4.4.3.5 Session Stop 

It is the point at which the MBMS user service determines that there will be no more data to send for some period of 
time - this period being long enough to justify removal of bearer resources associated with the service. At Session Stop, 
the bearer resources are released, 
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4.4.4 Broadcast Mode timeline 

4.4.4.1 Period between Service Announcement and Session Start 

Same as for Multicast mode. 

4.4.4.2 Period between Session Start and First Data Arrival 
Same ts for Multtcut mode. 

4.4.4.3 Period between Session Start and Session Stop 

Same as for Multicast mode, 

5 Functional Entities To Support MBMS 

To provide MBMS borer services existing tuncdoiul entities, GOSN, SOSN, RNC/BSC, perform seven! MBMS 
reined functions and procedures, some of which an specific to MBMS. An MBMS specific functional entity - 
Broadcast Multicast Service Centre (BM-SC) supports various MBMS user service specific service provisioning and 



5.1 



Toe BM-SC provides functions for MBMS user service provisioning and delivery. It may serve as an entry point for 
content provider MBMS transmissions, used to authorise and initiate MBMS Bearer Services within the FLMN and can 
be used to schedule and deliver MBMS truumiisions. 

The BM-SC is a functional entity, which must exist for each MBMS User Service. 

This section describes BM-SC functions, which art defined for the standardised MBMS User Services. Which of these 
functions are provided as general purpose capabilities to be used by multiple MBMS User Services and which are 
specific to a particular MBMS User Service is defined in conjunction with the definition of the standardised MBMS 
User Services, 

5.1.1 Content Provider Authentication, Authorization and Charging 

The BM-SC shall be able to authenticate f party content providers, providing content for MBMS transmissions. 

3 1 " party content providers may wish to initiate an MBMS iransmissioa In such cases, the BM-SC thall be able to 
authoriie content providers to transmit data over MBMS bearer services depending on operator policy. 

The BM-SC shall be able to verify the integrity of data received from content providers. 

The BM-SC shall be able to generate charging records for content provider transmitted data, 

5.1.2 MBMS Transport 

The BM-SC shall be able to provide the GGSN with transport associated parameters such as quality-of-service and 
MBMS service area, 

The BM-SC shall be able to initiate and terminate MBMS bearer resources prior to and following transmission of 
MBMS data. 

5.1.3 MBMS Transmissions 

The BM-SC should be able to accept content from external sources and transmit it using error resilient schemes (e.g. 
specialized MBMS codecs), 
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Further, the BM-SC might be used to schedule MBMS set 
provide this content using MBMS bearer services, 

transparent to the RAN and MBMS user service, 



session with an MBMS 
retransmissions. These retransmissions are 



5.1 .4 Service Advertisement and Description 

5.2 User Equipment 

ThellEshallsupportf^^ 

5.3 UTRAN/GERAN 
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5.4 SGSN 



Tw i SGSN shall provide support for intra-SGSN and inter-SGSN mobility nroceduna Snaifiullv ihi. ~ *. 

5.5 GGSN 

• Message Screening (not needed if the MBMS sources are internal in the PLMN); 

• ChwgingDitaCoUeciion; 

5.6 MBMS Data Sources and Content Provider 

The reference point firo the content provider to the BM-SC is not standardised. 

5.7 Optional Functional Element 

NOTE: ThefollowiagoreFFS. 

5.7.1 CSE 

5.7.2 CBC 

*M^Cw(W5^h^i,^i i ia» Irt . lllllllli 

5.7.3 OSA-SCS 

The BM-SC night use OSA-SCS to interact with third panics, 
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6 MBMS attributes and Parameters 
6.1 MBMS UE Context 

The MBMS UE Context contains UE-specific information related to a particular MBMS bearer service that the UE has 
joined. An MBMS UE Context is created in the UE, SGSN and GGSN when the UE join) an MBMS bearer service. In 
the SGSN, an MBMS UE Context is also created as a result of an inter-SGSN routing area update after the transfer of 
the MBMS UE Context from the old SGSN. It is FFS whether MBMS UE Contexts are created in the BM-SC. 

In lu mode, all MBMS UE Contexts of a UE are provided via MBMS UE Linking mechanism to the BSC/SRNC at 
least when the first PS RAB is established for the UE, or when the UE performs MBMS Multicast Service Activation, 
MBMS UE Contexts are provided to the BSC/SRNC regardless whether MBMS Sessions are ongoing or not (i.e. 
before, between and after Sessions). In addition, all MBMS UE Contexts of a UE are provided via MBMS UE Unking 
mechanism when a UE, which has an MBMS context active, moves to PMM-Conueeted state via the MBMS Service 
Request procedure for the purpose of MBMS. 

The existence of the MBMS UE context for Gb mode in the BSC is for further study. 

In the UE and SGSN, the MBMS UE Context is stored as part of the MM Context for the UE, The MBMS UE Context 
is stored in the GGSN, There is one MBMS UE Context per MBMS bearer service that the UE has joined. 

to the BSORNC, the MBMS UE Contexts are stored as part of the UE Context of the BSORNC. 

The content of the MBMS UE Context is deacribed ia Table 1, 

Table 1: MBMS UE Context 





Description 


UE 


SGSN 


GGSN 


RNC 


BSC 


BM-SC 


IP multicast address 


IP mufttcastaddrass IdenUfying an 
MBMS bearer that the UE has (dried. 


X 


X 


X 


X 


lu -X 
Gb ■ FFS 




APN 


Access Point Name on which this IP 
multicast address is defined. 


X 


X 


X 


X 


lu-X 
Gb-FFS 




TMGI 


Temporary Mobile Group Identity 
allocated to the MBMS bearer. 


X 










FFS 


Linked NSAPI 


NSAPl of the POP context used by 
the UE to canv IGMP/MLD BkmallinQ. 


X 


X 










IMS) 


IMSI identifying the user. 


[1) 


,(1) 


X 


(2) 


FFS 




FFS 


FFS 















(2) In the RNC, the IMSI is available within the UE Context which contains the MBMS UE Context. 

6.2 MBMS Bearer Context 

The MBMS Bearer Context, which is referred to as MBMS Service Context in RAN, contains all information 
describing a particular MBMS bearer service and is created in each node involved in the delivery of the MBMS data. 

An MBMS Bearer Context is created in the SGSN and GGSN when the first MBMS UE Context is created in the node 
or when a downstream node requests it. The MBMS Bearer Context is statically configured in the BM-SC; how this is 
done is out of the scope of this specification. The MBMS Bearer Context is created in the BSC/SRNC when a first 
MBMS UE Context is crested in BSC/SRNC. Session Start procedure may create MBMS Bearer Context in a 
BSORNC which has no MBMS Bearer Context yel Furthermore, it is FFS whether the state model described below is 
applicable as such to the RAN or whether it needs to be extended to cover the case of the RAN properly. 

An MBMS Bearer Context, once created, can be in one of two states reflecting the bearer plane resource status of the 
"ng MBMS be 
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No bearer plane re 



y ^Session Stop 

Bearer plane resourcu required 

Figure 6: MBMS Bearer Context State Model 

'Active' reflects lit juttt of on MBMS Bearer Context in which bearer plane resources are required in the network for 
the transfer of MBMS data. Thii state is maintained as long as there is a corresponding MBMS session ongoing. 

'Standby 1 reflects the state of an MBMS Bearer Context in which no bearer plane resources are required in the network 
for the transfer of MBMS data. This state is maintained as long as there ia no concspondiflg MBMS jessioa ongoing. 

The content of the MBMS Bearer Context is described in Table 2, 

Table 2: MBMS Bearer Context 



Parameter 


Description 


iiimiwirai 


IP mutet address 


IP multicast address Identifying the MBMS bearer 
described bv this MBMS Bearer Context 


11 


■ 


■ 




APN 


Access Point Name on which this IP multicast address 
Is defined. 


X 


X 


X 


FFS 


TMOI 


Temporary Mobile Group Identity elocatsd to the 
MBMS bearer service. 


X 


X 


X 


X 


State 


State of bearer plane resources ('standby 1 or 'active') 


FFS 


X 


X 


X 


Required MBMS 


Minimum bearer capabilities the UE needs to support 




X 


X 


X 


QoS 


Quality of Service required for the MBMS bearer 
service. 


X 


X 


X 


X 


MBMS Service Area 


"Area overwhlchthe MBMS bearerservice has to be 
distributed. 


X 


X 


X 


X 


List of downstream 
nodes 


List of downstream nodes that have requested the 
MBMS bearer service and to which notifications and 
MBMS date have to be forwards 




X 


X 


X 


Number of UEs' 1 
(FFS) 


Number of UEe hosted by the node that have joined the 
multicast MBMS bearer service. 


FFS 


X 


X 


FFS 



























Editor's note I : Number of UEs may be used to detennine when the last UE leaves the node and/or for content- 
provider charging. The RAN knows how many UEs in RRC-CONNECTED mode are interested in a 
multicast service, however it docs not know bow many UEs in RRC-IDLE mode are interested in the 
service, hence the meaning and relevance of this parameter for the RAN are FFS. 

6,3 Quality-of-Service 

It shall be possible for the network to control quality-of-service parameters for sessions of multicast and broadcast 
MBMS bearer services. All QoS attributes described in [3] are applicable to MBMS bearer services. Compared to point- 
to-poini bearer services the following limitations exist: 

■ For traffic class, only the background and streaming classes shall be supported. 



• For SDU error ratio, only higher values are supported, i.e. the values describing higher numbers of lost or 
corrupted SDUs (actual values are FFS). 

MBMS bearer services of background class are best suited for the transport of MBMS user services such as messaging 
or downloading. As for point-to-point bearer services, the network should, as far as possible, avoid dropping packets 
transported by a background class bearer service. Instead, buffering and shaping schemes should be applied to the 
traffic flow to adapt to the available resources and changing network conditions. The total transfer time is not critical 
for background class bearer services since the content must normally have been received in totality and stored in the UE 
before die user can access it 

MBMS bearer services of streaming class are best suited for the transport of MBMS user services such as streaming, As 
for point-to-point bearer services, the network should tninimise the packet transfer delay of streaming class bearer 
services as far as possible. Packet dropping should be the preferred traffic conditioning action applied to the traffic flow 
to adapt to the available resources, 

MBMS user services that would normally use MBMS bearer services of background class may however need to use a 
streaming class MBMS bearer service, This will allow to transfer each MBMS data unit at almost the same point in time 
to all cells of the MBMS service area, as otherwise UEs moving between cells while an MBMS session is ongoing may 
experience high packet loss due to possible time offsets of the data transmission between cells. The amount of packet 
loss depends on this time onset, the cell change time and the bilrale in particular. Otherwise the MBMS user service 
will have to provide sufficient redundancy within the data to be able to cope with the high packet loss. 

As the MBMS bearer service transfers data to many UEs in parallel and because of the lack of feedback channel on 
radio level low SDU error ratios are difficult to achieve, When the resulting packet error ratio is not suitable for the 
MBMS user service or when prevention of data loss is required, an MBMS user service may perform retransmission of 
MBMS data over point-to-point PDF bearer services on request from the receiver. 

6.3.1 MBMS QoS distribution tree 

MBMS data will be distributed to multiple users through a MBMS distribution tree that can go through many 
BSCs/RNCs, many SGSNs and one or more GGSNs. Furthermore some bearer resources may be shared between many 
users accessing the same MBMS bearer service in order to save resources. As a result, each branch of a MBMS 
distribution tree shall be established with the same QoS. 

MBMS distribution tree shall have the same QoS for all its branches. 

When a branch of the MBMS distribution tree has been crested, it is not possible for another branch (eg. due to arrival 
of a new UE or change of location of a UE with removal of a branch and addition of a new one) to impact the QoS of 
already established branches. 

There is no QoS value negotiation between UMTS network elements, This implies that some branches may not be 
established if QoS requirement cannot be accepted by the concerned network node, 

Also in RAN there is no QoS (renegotiation feature for the MBMS bearer service, 

6.4 Temporary Mobile Group Identity 

Temporary Mobile Group Identity (TMGI) is used for MBMS notification purpose. The BM-SC allocates a TMGI per 
MBMS bearer service that is unique within HPLMN. For Multicast MBMS bearer services the TMGI will be 
transmitted to UE via service activation procedure. For Broadcast Service the TMGI can be obtained via service 
announcement see " Service Announcement". 



7 



7.1 Application Adjunct Entity 

For the MBMS "file download" service, there arc several use cases where it may be beneficial for the UE to contact a 
network entity (the Application Adjunct Entity ( AAE)) after the download is complete in order, eg, to permit errors in 
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the Tile lo be corrected; to permit the network to charge for a successful download; to pass a decrypt key to the UE; etc. 
The AAE is logically pan of the BM-SC. 

Note: use of the AAE might also be beneficial for some MBMS Streaming Soviets. 

Cue is needed to ensure that the uplink traffic does not overload the network (radio, RNC, BSC, SGSN, GCSN and 
BM-SC). One way for this load to be distributed is for the BM-SC to allocate the address of (one of many) AAEs to the 
UE at activation time, along with parameters) (bat are used to generate a random time dispersion of the uplink traffic. 



8 MBMS Procedures 



8.1 MBMS Notification 

8,1.1 lu mode notification (UTRAN and GERAN) 

When an MBMS Session starts, UEs interested in the MBMS bearer service (PMM-CONNECTED UEs and PMM- 
IDLE UEi) shall be notified. 

MBMS Session attributes such as Session Identifier and the MBMS service Area are made available in all interested 
RNCs during the Session Stan procedure. Other parameters are ITS. 

For radio efficiency reasons, the UTRAN may select on per cell basis whether to establish point-to-point or point-to- 
multipoint links for the distribution of MBMS data to the UEs, 

In order to perform this election, the UTRAN requests UEs to move to PMM-CONNECTED / RRC-CONNECTED 
state by menu of MBMS notification sent in the MBMS service Area. 

The fact that to MBMS oolification moves the UEa back to PMM-CONNECTED or to RRC-CONNECTED state is 
FFS, subject to RAN decision. 

The aact number of UEs moved to PMM-CONNECTED / RRC-CONNECTED state is a decision of RAN node, It is 
not necessary for all UEs to move to PMM-CONNECTED/ RRCCONNECTED in order for the RAN to decide to use 
point-to-multipoint, other UEa may remain in IDLE state. This is a UTRAN choice (based on RRM criteria. ..), FFS in 
RAN group. 

Following the decision to set up point-to-point or point-tc-tnultipoint links, the number of UEs that need to be 
maintained in CONNECTED state or moved to IDLE state for MBMS data reception u alio a decistoa of a RAN node, 



8.1,2 A/Gb mode notification (GERAN) 



When an MBMS Session starts, UEs interested in the MBMS bearer service (READY UEs and STANDBY) shall be 
notified. The MBMS notification triggers detection or counting of UEs per cell for selection of the most appropriate 
MBMS radio bearer, 

MBMS Session attributes such as Session Identifier, MBMS Service Area, QoS are made available in all interested 
BSCs that are connected to a registered SGSN by the Session Start procedure. 



8.2 MBMS Multicast Service Activation 

The MBMS mulucast service activation procedure registers the user in the networic to enable the reception of data Horn 
a specific multicast MBMS bearer service. The activation is a signalling procedure between the UE and the network. 
The procedure establishes MBMS UE contexts in UE, SGSN and GGSN and BSC/RNC for each activated mulucast 
MBMS bearer service comparable to regular PDP contexts. 



| RAN 



5. Request MBMS ( bntexl Activation 



8, Security Function 



15. Activate MBMS Context Accept 



Context Request 



Provision of MBMS UEi 
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J 1 GGSN 1 



MBMS Autboroatid Request 



MBMS Authorizatid Response 



4, MBMS Notificatio i Request 



7. MBMS Notified >n Response 



1 GGSN 1 
9. Create MBMS Cot text Request 



10 MBMS Auttorizati m Request 



MBMS Authorialic i Response 



13. MBMS Registrati in Request 
13. MBMS Registrati >n Response 



ll.MBMS Registrat on Request 
11. MBMS Registra ion Respons 
12. Create MBMS Context Response 



Figure 7: The activation of an MBMS multicast service 

1. The UE activates a default, typically best-effort PDP context if not already established. This can be aPDP 
context used for basic IP services like WAP or Internet access, or it might be the signalling PDP context used for 
IMS access. 

2. The UE sends an IGMP (IPv4) or MID (IPv6) Join message over the default PDP context to signal its interest in 
receiving a particular multicast MBMS bearer service identified by an IP multicast address. 

3. The GGSN sends an MBMS Authorization Request seeking authorization for the activating UE to receive data, 
The authorization decision is provided in the MBMS Authorization Response together with the APN to be used 
for creation of the MBMS UE context If the MBMS Authorization Response indicates that the UE is not 
authorized to receive the MBMS data the process terminates with no additional message exchange. 

4. The GGSN receives the IGMP/MLD Join request and sends an MBMS Notification Request (IP multicast 
address, APN, Linked NSAPI) to the SGSN. Linked NSAPI is set equal to the NSAP1 of the PDP context over 
which the Join request was received. The IP multicast address is the one requested by the UE in the Join request. 
The APN may be different from the APN to which the default PDP context has been activated. In any case, the 
APN may resolve to a GGSN that is different from the GGSN receiving the IGMP/MLD Join request. The 
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CGSN starts a MBMS Activation Timer as CCSN may receive no response, e.g. in case SGSN or UE does not 
support MBMS. 

5. The SGSN sends s Request MBMS Context Activation (IP multicast address, APN, Linked NSAP1) to the UE to 
request it to activate an MBMS context. Linked NSAPI allows the UE to associate the MBMS Context with the 
PDP context over which it sent the IGMP/MLD Join message in step 2. , 

6. The UE creates an MBMS UE context and sends an Activate MBMS Context Request (TP multicast address, 
APN, MBMS bearer capabilities) to the SGSN. The IP multicast address identifies the MBMS multicast service, 
which the UE wants to join/activate. An APN may indicate a specific GGSN. The MBMS bearer capabilities 
indicate the maximum QoS the UE can handle. 

7. The SGSN sends a MBMS Notification Response (Cause) to the GGSN that sent the MBMS Notification 
Request, where Cause shall indicate successful or unsuccessful MBMS context activation for the reason of 
SOSN or UE (Cause is FFS). Upon reception of the response message with Cause indicating unsuccessful 
operation or tune-out of the MBMS Activation Timer in the GGSN, the GGSN may fallback to IP multicast 
access as defined in 3GPPTS 29.061 [4], 

S. Security Functions may be performed, e.g. to authenticate the UE, 

9, It is FFS whether the SGSN performs a subscription check for the requested MBMS bearer service identified by 
the IP multicast address and APN or whether another network entity performs this check. The SGSN creates an 
MBMS UE context and sends a Create MBMS Context Requests (IP multicast address, APN) to the GGSN. 

1 0, The GGSN sends an MBMS Authorization Request seeking authorization for the activating UE. The 
authorization decision is provided in the MBMS Authorization Response. 

1 1, If the GGSN does not have the MBMS Bearer Context information for this MBMS bearer service, the GGSN 
sends a MBMS Registration Request to the BM-SC. See subclause "MBMS Registration Procedure". 

If no TMGI has been allocated for this MBMS bearer service, the BM-SC will allocate a new TMGL This TMG1 
will be passed to GGSN and SGSN via the MBMS Registration Response message and further to UE via 
Activate MBMS Context Accept message. 

The BM-SC responds with a MBMS Registration Response containing the MBMS Bearer Context information 
for this MBMS bearer service and adds the identifier of the GGSN to the "list of downstream nodes" parameter 
in its MBMS Bearer Context See subclause "MBMS Registration Procedure". 

12, The GGSN creates an MBMS UE context and sends a Create MBMS Context Response to the SGSN. 

1 3, If the SGSN does not have the MBMS Bearer Context information for this MBMS bearer service, the SGSN 
sends a MBMS Registration Request to the GGSN. See subclause "MBMS Registration Procedure". 

The GGSN responds with a MBMS Registration Response containing the MBMS Bearer Context information 
for this MBMS bearer service and adds the identifier of the SGSN to the "list of downstream nodes" parameter in 
its MBMS Bearer Context See subclause "MBMS Registration Procedure". 

U.The SGSN provides RAN with the MBMS UE Context(s) if at least one PS RAB is established for the UE 

lS.The SGSN sends an Activate MBMS Context Accept (MBMS bearer capabilities) to the UE. The MBMS bearer 
capabilities indicate the maximum QoS that is used by this MBMS bearer service and the UE may take it into 
account when further MBMS bearer services are activated. If the SGSN determines that the UE's MBMS bearer 
capabilities are lower than the Required MBMS Bearer Capabilities the SGSN rejects the request for activation 
of an MBMS context indicating an appropriate cause and starts the deactivation of the already established 
MBMS UE contexts. 



8,3 MBMS Session Start Procedure 

The BM-SC initiates the MBMS Session Start procedure when it is ready to send data. This is a request to activate all 
necessary bearer resources in the network for the transfer of MBMS data and to notify interested UEs of the imminent 
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for the corresponding MBMS bearer service and to all BSCs/RNCs that are connected to a registered SGSN. In addition 
the procedure allocates the bearer plane to all registered GGSNs and all registered SGSNs and to BSCs/RNCs that 
respond to the session start accordingly. 

The overall Session Start procedure is presented in the following figure: 

I UE I | BSC/RNC I | SGSN | I GGSN | | BM-SC | 



I. Session Start Req test 



3. MBMS Session Start Request 



3. MBMS Session Start Response 



2, MBMS Sessions art Request 



2. MBMS Sessions art Response 



Through this procedure, MBMS session attributes such as QoS, MBMS service Area (owkuig/non-tracking area are 
FFS), estimated session duration if available are provided to the GGSN(s) and SGSN(s) that have previously registered 



| 4. RAN Resource Setup 



Figure 8 Session Start procedure 

1, The BM-SC sends a Session Start Request message to indicate the impending start of the transmission and to 
provide the session attributes (QoS, MBMS service Area, tstinated session duration.. .) to tie GGSNs listed in 
the "list of downstream nodes" parameter of the corresponding MBMS Bearer Context The BM-SC sets the 
state attribute of its MBMS Bearer Context to 'Active'. The GGSN stores the session attributes in the MBMS 
Bearer Context, sets the state attribute of its MBMS Bearer Context to 'Active' and sends a Session Start 
Response message to the BM-SC. 

2, The GGSN sends an MBMS Session Start Request message to the SGSNs listed in the "list of downstream 
nodes" parameter of the corresponding MBMS Bearer Context The SGSN stores the session attributes in the 
MBMS Bearer Context, sets the state attribute of its MBMS Bearer Context to 'Active' and responds with an 
MBMS Session Start Response message providing the TEID for bearer plane that the GGSN shall use for 
forwarding the MBMS data, 

3, The SGSN sends an MBMS Session Start Request message including the session attributes to each BSC/RNC 
that is connected to this SGSN, The BSC/RNC responds with an MBMS Session Start Response to the SGSN. If 
the BSC/RNC serves the MBMS Service Area it stores the session attributes in the MBMS Service Context, sets 
the state attribute of its MBMS Service Context to 'Active' and responds with an MBMS Session Start Response 
message and the RNC includes the TED in the MBMS Session Start Response message for the lu bearer plane 
that the SGSN shall use for forwarding the MBMS data. An RNC receiving multiple MBMS Session Start 
Request messages includes lu bearer plane parameters only into one MBMS Session Start Response message to 
establish only one lu bearer plane to one SGSN. 

4. The BSC/RNC establishes the necessary radio resources for the transfer of MBMS data to the interested UEs. 

Note: The upstream node normally provides the MBMS Session Start Request message once per MBMS 
session to a downstream node. Due to "Intra Domain Connection of RAN Nodes to Multiple Core 
Network Nodes" however, an RNC may receive the MBMS Session Start Request message fiom several 
SGSNs. 



8,4 MBMS Registration Procedure 

The MBMS Registration is the procedure by which a downstream node informs an upstream node that it would like to 
receive session attributes and data for a particular MBMS bearer service in order to distribute it further downstream, 
This procedure builds up a distribution tree for the delivery of MBMS session attributes and data from the BM-SC to 
the UEs interested in the service, This procedure results in the set-up of a corresponding MBMS Bearer Context in the 
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The MBMS Registration procedure is initiated: 

" ^ * i!!SS UE ^ m k 1 ^ mm *** seni « « ««ied in (bo SGSN or GCSN (see 
sutaleuse "MBMS UE Context") and the eontapondug MBMS Bearer Context ii not already estabbhri in 

• When an MBMS Resutradon Request for 6 particular MBMS bwrer service U received from e dovmstream 
node but the corresponding MBMS Bearer Context is not established in the node; or 

• When a DRNC delect! that it hosts UEs interested in the MBMS bearer service. 

NOTE: The term 'downstream' and 'upstream' refer to the topological position of one node with respect to 
another and relative to the direction of the MBMS data flow, it from BM-SC to UE. 

DjO Q«] □GST] [jmF] 
1. MBMS Resjimtio l Request 

2, MBMS Registratio i Request 



6. MBMS Regiitrat )n Response 



3. MBMS Registratio i Request 



4, MBMS Registrar] 



i MBMS Regiitratio i Response 



•^MS^ionjtai Prcedure] 



Figure 9: MBMS Registration procedure 
l ' ^ ^ 11 ^ U& Crested in the MBMS bearer service, die DRNC sends a MBMS 

2. If the SGSN has no MBMS Bearer Context for an MBMS rxsrer service and the SGSN receives an MBMS 

Iv f^l^^^ 6 10 1,16 H0W 1116 SGSN "'^ 11 GGSN i" -Stter of inXeoution- it 
may for instance be based on prior signalling related to a particular UE or via APN resolution. BmeDU, "° n ' 

3. If the GGSN has no MBMS Bearer Context for an MBMS bearer service and the GGSN receives an MBMS 
GGSN for an MBMS bearer service for which the GGSN has no MBMS Bearer Context the GOSN sends a 

RiLnni! nwm^ •"tn in its MBMS Bearer Context and responds with a MBMS Registration 

BM-SC u however FFS in general, If the MBMS Bearer Context is in the 'Active' ttatothe BM-SC initiates Ik 
Saston Star, procedure with the CK3SN, « described in clause "MBMS Se«S^ ftc^ 

5. If the GGSN receives a Registration Request from the SGSN in step 2, the GGSN: 

• adds the identifier of the SGSN to the "list of downstream nodes" parameter in its MBMS Bearer Context, 
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- responds with an MBMS Registration Response (TMGI, Required Bearer Capabilities) message, and 

• if the MBMS Bearer Context is in the 'Active' state, initiates the Session Start procedure with the SGSN, as 
described in clause "MBMS Session Start Procedure". 

6. If the SGSN received MBMS Registration Request from the DRNC in step 1, the SGSN: 

. adds the identifier of the RNC to the "list of downstream nodes" parameter in its MBMS Bearer Context, 

• responds with an MBMS Registration Response message, and 

• if the MBMS Bearer Context is in the 'Active' state, initiates the Session Start procedure with the DRNC, as 
described clause "MBMS Session Start Procedure". 



8.5 MBMS Session Stop Procedure 

The BM-SC initiates the MBMS Session Stop procedure when it considers the MBMS session to be terminated. The 
session is typically terminated when there is no more MBMS dsn expected to be transmitted for a sufficiently long 
period of time to justify a release of bearer plane resources in the network. The procedure is propagated to all SGSNs 
and GGSNs that are registered for the corresponding MBMS bearer service and to BSCs/RNCs that have an established 
lu bearer plane with an SGSN. 

The overall MBMS Session Stop procedure is presented in the following figure: 

1 UE I 1 BSC/RNC 1 1 SGSN [ | GGSN | | BM-SC | 



I. Session Stop Reqiest 



3. MBMS Session Sop Request 



3. MBMS Session Sop Response 



2. MBMS Session Sop Request 



2. MBMS Session Sop Response 



I. Session Stop Res; onse 



J 4. RAN Resource Release 

Figure 10: MBMS Session Stop procedure 

1 , The BM-SC sends a Session Stop Request message to all GGSNs listed in the "list of downstream nodes" 
parameter of the affected MBMS Bearer Context to indicate that the MBMS session is terminated and the bearer 
plane resources can be released. The BM-SC sets the state attribute of its MBMS Bearer Context to 'Standby*. 

2, The GGSN sends an MBMS Session Stop Request message to all SGSNs listed in the "list of downstream 
nodes" parameter of the affected MBMS Bearer Contest, releases the corresponding bearer plane resources 
towards these SGSNs and sets the state attribute of its MBMS Bearer Context to 'Standby'. 

3. The SGSN releases the TED and bearer plane resources on which it was receiving MBMS data Iron the GGSN 
for the affected MBMS bearer service and sends an MBMS Session Stop Request message to all BSCs/RNCs 
that have a bearer plane established with the SGSN. 

4. The RNC releases the affected radio and Iu resources; the BSC releases the affected radio resources. 
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MBMS De-Registration Procedure 



The MBMS Dc-Rcgistration is the procedure by which a downstream node informs us upstream node that it does not 
need a to receive signalling, session attrfoutes and data for a particular MBMS bearer service anymore and therefore 
would like to be removed from the corresponding distribution 

He MBMS De-registration procedure is initiated; 

■ By the SGSN or COSN when the last MBMS UE Context tor a particular MBMS bearer service is deleted fan 
tne node and the "list of downstream nodes" parameter in the corresponding MBMS Bearer Content is empty; 

• Jy the SGSN or GGSN when the last node registered in the list of downstream nodes" do-registers from an 
MBMS bearer service for which there is no corresponding MBMS UE Context; or 

• By the DRNC that registered at so SGSN when it deletet the sssociattd MBMS Service Context. 

1. RNC 1 | SGSN 1 



A. MBMS Deregistn ion Request 



A. MBMS Peregistra ion Response 



1 «jSN 1 
B. MBMS rjeregistro ion Request 



B, MBMS Deregistn ion Response 



BM-SC 
CDeregistrationRi quest 



C. registration Risponse 



Figure 11; MBMS De-Registration Procedure 

th DRNC requests the ^registration from the MBMS bearer service to its parent SGSN, As an implementation 
option, the RNC may decide not to de-register from the MBMS bearer service immediately when these 
conditions axe met, e.g. in order to avoid umiecesiary signalling in the case where the RNC would auio need the 
same MBMS bearer service shortly after. 

55? T k iiMa of h m I** ** 1* of downshtain oodes" parameter of the afTected 
NfflMS Bearer Context and corJlrms the operadoo by sending an MBMS De-Registration Response message to 
the RNC. If an lu bearer plane had been established between the RNC and the SGSN for this MBMS bearer 
service, the Iu bearer plane is released. 

SGSN has no MBMS UE Contexts linked to that MBMS Bearer Context, the SGSN sends an MBMS De- 
Registratioa Request (IP multicast address, APN) message to its upstream OOSN. 

Tta GGSN removes the identifier of the SGSN from the "list of downstream nodes" parameter of the affected 
SSSS?? - " 1 811(1 Mnfi nM ihe operation by sending an MBMS De-Repstration Response mesaafle to 
the SGSN. If a bearer plane had been established between the SGSN and the GGSN for this MBMS bearer 
service, the bearer plane is released. 
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C. When the "list of downstream nodes" of a particular MBMS Bearer Context in the GGSN becomes empty and 
the GGSN has no MBMS UE Contexts linked to that MBMS Bearer Context, the GGSN sends a De-Registration 
Request (IF multicast address, APN) message to the BM-SC. The exact nature of the signalling between GGSN 
and BM-SC is however ITS in general, If a bearer plane had been established over Gi for this MBMS bearer 
service, the bearer plane is released, 

The BM-SC removes the identifier of the GGSN from the "list of downstream nodes" parameter of the affected 
MBMS Bearer Context and confirms the operation by sending a De-Registration Response message to the 

GGSN. 

8.6,1 BM-SC initiated MBMS De-Registration Procedure 

This MBMS De-Registration Procedure is initiated by BM-SC when the specific MBMS bearer service is terminated. 
This procedure tears down the distribution tree for the delivery of session attributes and MBMS data. This procedure 
results in releasing of all MBMS Bearer Contexts and associated MBMS UE Contexts in the nodes along the 
distribution tree. 



I If I I RNC I I SGSN I I GGSN I 



2. MBMS Deregtstr n'on Request 



3. MBMS Deregistition Request 



3. MBMS Dertguti idem Response 



4. MBMS Session! top Request 
4. MBMS Session Sop Response 



, MBMS Deregistn ion Response 



I.Derepitran'onRisponse 



figure 12; BM-SC Initiated MBMS De-Registration Procedure 

1. The BM-SC sends a De-Registration Request message to all GGSNs contained in the "list of downstream nodes 1 ' 
parameter of the corresponding MBMS Bearer Context to indicate the session is terminated and any related 
MBMS bearer resources shall be released. 

The GGSN returns a De-Registration Response message to the BM-SC. The BM-SC releases all MBMS UE 
Contexts and removes the identifier of the GGSN from the "list of downstream nodes" parameter of the 
corresponding MBMS BearercontexL 

2. The GGSN sends an MBMS De-Registration Request message to all SGSNs contained in the "list of 
downstream nodes" parameter, of the corresponding MBMS Bearer Context, The SGSN returns an MBMS De- 
registmioo Response message to the GGSN. The GGSN releases all MBMS UE Contexts and the affected 
MBMS Bearer Context. Ifa bearer plane had been established over Gi for this MBMS bearer service, the bearer 
plane is released, 

3. The SGSN sends an MBMS De-Registration Request message to all RNCs listed in the "list of downstream 
nodes" parameter of the corresponding MBMS Bearer Context The RNC returns an MBMS De-Registration 
Response message to the SGSN. The SGSN releases all MBMS UE Contexts and the affected MBMS Bearer 
Cootext, If a bearer plane had been established between the SGSN and the GGSN for this MBMS bearer service, 
the bearer plane is released. 
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tenmnatcd, m that «hc UE can locUy deactivate iti MBMS UE cental, detailed precede acc FFS. 



MBMS Multicast Service Deactivation 
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am ower service and send) a UE Removal Request (IP multicast address, APN, IMS1) to the GGSN that 

MAMS Mutat Service Activation"). The exact nature of the signalling between GGSN and BM-SC is 
However FFS in general. The BM-SC may also initiate the deactivatioo of an MBMS UE Context for service- 

aL? i n i ?^ IIV,,tIOn Request ^ ^Ull,1CU, lddras - ^ ^S 1 ) to the SGSN. The IP multicast address 

ZEl&m SGSN acknowledges recepUcn of Ote MBMS UE Context Deactivation Request by 
Mnehng an MBMS UE Context Deactivation Response to the GGSN. 

i^tionofM 

6. The UE deletes the MBMS UE Context and sends a Deactivate MBMS Context Accept (TT) to the SGSN. 

7. If dedicated radio resources ore currently assigned to the UE for the reception of the MBMS data, the RAN 

1 iSSSS^ e MBMS Context Accept or for other reasons (e.g. due to missiog periodic 
Context This GGSN may be different from the GGSN that receives IGMP Leave reouest in step 1 . 

'^^Ndwnothavt any more users intertsted in uus MBMS bearer service and the "lis. of downstream 



Figure 13: MBMS Multicast Service Deactivation 
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Figure 14; mter S6SN Routelng Area Update 
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2) The context transfer in step 2 includes the transfer of the MBMS UE Contexts). 

7) The new SGSN sends Update MBMS UE Context Request to the OGSNs concerned. The CGSNs update their 
MBMS UE Context fields and return Update MBMS UE Context Response. 

1 2)If the old SGSN dots not have any more MBMS UE Contexts for the MBMS bearer service(s) and the "list of 
downstream nodes" in the corresponding MBMS Bearer Context is empty, the SGSN sends an MBMS 
Deregistration Request to the GGSN. The GGSN responds with an MBMS registration Response and removes 
the identifier of the SGSN from the "list of downstream nodes" parameter in its MBMS Bearer Context See 
subclause "MBMS Deregistration Procedure". 

I ))The new SGSN verifies for each MBMS UE Context received whether it has a corresponding MBMS Bearer 
Context. For each MBMS Bearer Context the SGSN does not already have the SGSN creates an MBMS Bearer 
Context (in "Standby" state) and sends an MBMS Registration Request to a GGSN. This registration is described 
in subclause "MBMS Registration Procedure", 

8.1 1 Inter SGSN Serving RNS Relocation Procedure 

no procedure is performed when the SGSN changes due to SRNS relocation. It bases on the SRNS Relocation 
procedure specified in TS 23.060. The procedure is performed regardless whether MBMS sessions are ongoing or not 
Tne handling of any PDP contexts established by the UE is not changed compared to the procedure without MBMS. 
The procedure described below does not show all details of the SRNS relocation procedure. Only for the MBMS 
specific additions the steps axedeseribed. 



3GPP TS 23.246 V.8,1,0 (2003-12) 



H B E 



.Awardin g 



8, RehKadonfommU 

9. Retocatlon ietod 



Infatuation^ 



>. lu Rtfeaw Conplsta 



rt of Rado Access Bum 



4. Relocallonl equest Actowwladge 



^, forwrd ReloeaDon Reapon t 



E3 



w Cpnfa 
11. Relocatlon|ConipletB 



12. Fofwarri RalocaBon Con^p >to 



J&MBMS Oeretfatratton Reqi al 



12. Foiwrt RdocatlooComj ite Adcnawledg 

13. UpdateP IP Context Requeat 



. 13. Update P IP Context Reapon$a 



14. MBMS Redjstraton Request 

iJ'mbmsfS 



I rfSUECwtextRequest 



^7. Update Mt AS US Context Reapowa 



i-'' 

Figure 15: SRNS Relocation Procedure 

3) The context transfer in step 3 includes the transfer of the MBMS UE Contexts). 

!4)The new SGSN verifies for each MBMS UE Context received whether it has e corresponding MBMS Bearer 
Context For etch MBMS Bearer Context not yet existing in the SGSN the SGSN creates an MBMS Bearer 
Context (in "Standby" state) and sends an MBMS Registration Request to a GGSN. This registration is described 
in subclause "MBMS Registration Procedure", 
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16) lf the old SGSN does not have any more MBMS UE Contexts for this MBMS bearer service and the "list of 
downstream nodes" in the corresponding MBMS Bearer Context is empty, the SGSN sends an MBMS De- 
registration Request to the GGSN. The GGSN responds with an MBMS De-registration Response and removes 
the identifier of the SGSN from the "list of downstream nodes" parameter in its MBMS Bearer Context. See 
subclause "MBMS De-registration Procedure". 

17) The new SGSN sends Update MBMS UE Context Request to the GGSNs concerned. The GGSNs update their 
MBMS UE Context fields and return Update MBMS UE Context Response. 

8.12 MBMS Broadcast Service Activation 

MBMS Broadcast service activation is the procedure by which a UE locally activates a broadcast MBMS bearer 

■ The MBMS broadcast service activation procedure does not register the user in the network. There is no MBMS 
bearer service specific signaling exchanged between the UE and the Network. 



• The broadcast service activation procedure does not establish MBMS UE contexts in UE, S( 

8.13 MBMS Broadcast service de-activation 

The MBMS Broadcast service derivation by the UE is local to the UE, i,e, without interaction with the Network, 

8.14 



The BM-SC initiates the MBMS Session Start procedure when it is ready to send data. This is a request to activate all 
necessary bearer resources in the network for the transfer of MBMS data. It is FFS whether it b alao used to ootify 
interested UEa of the start of the transmissioD. 

Tnrough this procedure, MBMS session attributes such as QoS, MBMS service Area (trokM/non-tracking area ait 
FFS) are provided to all the GGSN(s), SGSN(s) and BSCs/RNCs. In addition the procedure allocates the bearer plane to 
all GGSNs and al] SGSN. and to BSCsWCa that respond to the MBMS aesaicm start accwdingly. 

The overall MBMS Broadcast Session Start procedure is presented in the following figure; 

i " E I I BSCjRNC I | SGSN"! |~GGSN~] [1m1c~| 



1. Session Start Reqiesl 



. MBMS Session S art Response. 



2. MBMS Sessions art Request 



2. MBMS Sessions art Response. 



4. RAN Resource Setup 



. Session Start Res (onse. 



i 1 r 

Figure 18 Session Start procedure for Broadcast MBMS Bearer Service 

I ) The BM-SC sends a Session Start Request message the impending start of the transmission and to provide the 
MBMS session attributes (QoS, MBMS service Area..,) to a GGSN of the PIWN. The BM-SC sets the state 
attribute of its MBMS Bearer Context to 'Active'. The GGSN creates a MBMS Bearer Context, stores the 
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session attributes, sen the stale attribute of this MBMS Bearer Context to 'Active' and sends a Session Start 
Response message to the BM-SC. 

2) The GGSN sends an MBMS Session Start Request message to til its SGSNs, The SGSN creates a MBMS 
Bearer Context, stores the session attributes, sets the state attribute of this MBMS Bearer Context to 'Active' and 
responds with an MBMS Session Start Response message providing the TED for bearer plane that the QOSN 
shall use for forwarding the MBMS date. 

)) The SCSN sends an MBMS Session Start Request message including the session attributes to each BSC/RNC 
that is connected to this SOSN, The BSORNC responds with an MBMS Session Start Response message to the 
SGSN. If the BSC/RNC serves the MBMS service Area, it creates a MBMS Bearer Context, stores the session 
attributes in this MBMS Service Context, sets the state attribute of its MBMS Service Context to 'Active' and 
responds with an MBMS Session Start Response message, and the RNC includes the TEID in the MBMS 
Session Start Response message for the lu bearer plane that the SGSN shall use for forwarding the MBMS data. 
An RNC receiving multiple MBMS Session Start Request messages from different SGSNs includes Iu bearer 
plane parameters only into one MBMS Session Start Response message to establish only one lu bearer plane to 
one SGSN. 

4) The BSC/RNC establishes the necessary radio resources for the transfer of MBMS data to the interested UEs. 

Note: The upstream node normally provides the MBMS Session Start Request message once per MBMS 
session to a downstream node. Due to "Intra Domain Connection of RAN Nodes to Multiple Core 
NetworlcNodes" however, tn RNC may receive the MBMS Session Start Request message from several 
SGSNs. 



It shall be possible to colled charging information for the multicast mode. It shall also be possible to collect charging 
information for MBMS services in visited networks, 

MBMS shall collect charging information about the transmission of MBMS broadcast or multicast data that are 
provided by content or service providers (e.g. 3* parties). This shall enable billing of broadcast and multicast content or 



To enable billing of broadcast and multicast content providers, data shall be collected at the BM-SC. 

NOTE SGSN, GGSN and BM-SC generate charging data for the transmitted data, always under the assumption 
that the UEs are within the MBMS service area. If the MBMS service area is less than the PLMN, then 
there is the possibility that a UE will have moved outside the MBMS service area. Charging data will still 
be generated for that UE causing an inaccuracy in the data. This inaccuracy increases as the size of the 
MBMS service area is decreased. 



8.15 MBMS UE Linking mechanism 

UE Linking is the process by which UE MBMS contexts) is (are) provided to RAN. 

MBMS UE linking procedure is performed when the UE is PMM-CONNECTED at least in the following cases. 

• When a UE which has joined MBMS is moved to the PMM CONNECTED state end sets up a PS RAB.Tnis 
nay happen at any point in time i.e. before, during and between Sessions. 

- When a UE joins the service and is in the PMM CONNECTED state due to an existing PS RAB. Thia may 
happen at any point in time i.e. before, during and between Sessions. 

• When a UE is moved to the PMM CONNECTED state only for MBMS purpose via Service Request procedure. 
This may happen at any point in time during a MBMS session. 

The UE linking is performed to link a specific UE to an MBMS service, It provides the Ust of MBMS Service Ids 
activated by the UE to the SRNC If no MBMS service context related to the MBMS service Id exists then SRNC 
creates an MBMS service context after this procedure. 

8.16 MBMS Service Request Procedure 

For MBMS, when UTRAN wants to count the number of users that are interested in a specific MBMS service present in 
a cell, it will request a percentage of the interested UEs to transit to PMM-CONNECTED state. The MBMS Service 
Request procedure is used by a UE in PMM-HJLE state to move to PMM-CONNECTED state. 



9 Security 

Security of MBMS is found in 3GPP TS 33.246 [5], 



10 Charging requirement 

MBMS architecture shall support on-line and off-line charging, 
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